Hardware-management-console-initiated data protection

ABSTRACT

A method for protecting data in a storage system is disclosed. In one embodiment, such a method includes detecting, by a first hardware management console, first battery-on status associated with a first uninterruptible power supply. The method further detects, by a second hardware management console, second battery-on status associated with a second uninterruptible power supply. The method communicates, from the first hardware management console to the second hardware management console, the first battery-on status. The method then triggers, by the second hardware management console, a dump of modified data from memory to more persistent storage upon detecting both the first battery-on status and the second battery-on status. A corresponding system and computer program product are also disclosed.

BACKGROUND Field of the Invention

This invention relates to systems and methods for protecting data inmulti-server storage systems.

Background of the Invention

In an enterprise storage system such as the IBM DS8000™ enterprisestorage system, a pair of servers may be used to access data in one ormore storage drives (e.g., hard-disk drives and/or solid-state drives).During normal operation (when both servers are operational), the serversmay manage I/O to different logical subsystems (LSSs) within theenterprise storage system. For example, in certain configurations, afirst server may handle I/O to even LSSs, while a second server mayhandle I/O to odd LSSs. These servers may provide redundancy and ensurethat data is always available to connected hosts. When one server fails,the other server may pick up the I/O load of the failed server to ensurethat I/O is able to continue between the hosts and the storage drives.This process may be referred to as a “failover.”

Each server in the storage system may include one or more processors andmemory. The memory may include volatile memory (e.g., RAM) as well asnon-volatile memory (e.g., ROM, EPROM, EEPROM, flash memory, local harddrives, local solid state drives, etc.). The memory may include a cache,such as a DRAM cache. Whenever a host (e.g., an open system or mainframeserver) performs a read operation, the server that performs the read mayfetch data from the storage drives and save it to its cache in the eventit is required again. If the data is requested again by a host, theserver may fetch the data from the cache instead of fetching it from thestorage drives, saving both time and resources. Similarly, when a hostperforms a write, the server that receives the write request may storethe modified data in its cache, and destage the modified data to thestorage drives at a later time. When modified data is stored in cache,the modified data may also be stored in non-volatile storage (NVS) ofthe opposite server so that the modified data can be recovered by theopposite server in the event the first server fails. In certainembodiments, the NVS is implemented as battery-backed volatile memory inthe opposite server.

When a storage system such as the IBM DS8000™ enterprise storage systemexperiences a power outage, the modified data in the NVS may be quicklycopied using battery power to more persistent storage on the server(e.g., a local disk drive, solid state drive, and/or flash drive on theserver). The energy in the backup battery needs to be sufficient tocomplete the copy process. If a battery is degraded or the copy processis not initiated quickly enough after the storage system goes on batterypower, the battery may not have sufficient energy to complete the copyprocess. In such cases, data loss may result.

In view of the foregoing, what are needed are systems and methods toensure that modified data in an NVS is not lost in the event of a poweroutage. Further needed are systems and methods to ensure that, in theevent of a power outage, data is promptly and reliably copied from theNVS to more persistent storage.

SUMMARY

The invention has been developed in response to the present state of theart and, in particular, in response to the problems and needs in the artthat have not yet been fully solved by currently available systems andmethods. Accordingly, systems and methods have been developed to moreeffectively protect modified data in a storage system. The features andadvantages of the invention will become more fully apparent from thefollowing description and appended claims, or may be learned by practiceof the invention as set forth hereinafter.

Consistent with the foregoing, a method for protecting data in a storagesystem is disclosed. In one embodiment, such a method includesdetecting, by a first hardware management console, first battery-onstatus associated with a first uninterruptible power supply. The methodfurther detects, by a second hardware management console, secondbattery-on status associated with a second uninterruptible power supply.The method communicates, from the first hardware management console tothe second hardware management console, the first battery-on status. Themethod then triggers, by the second hardware management console, a dumpof modified data from memory to more persistent storage upon detectingboth the first battery-on status and the second battery-on status.

A corresponding system and computer program product are also disclosedand claimed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered limiting of its scope, the embodiments of the inventionwill be described and explained with additional specificity and detailthrough use of the accompanying drawings, in which:

FIG. 1 is a high-level block diagram showing one example of a networkenvironment in which systems and methods in accordance with theinvention may be implemented;

FIG. 2 is a high-level block diagram showing one example of a storagesystem for use in the network environment of FIG. 1;

FIG. 3 is a high-level block diagram showing various components taskedwith supplying power to a storage system such as that illustrated inFIG. 2;

FIG. 4 is a high-level block diagram showing the system of FIG. 3 when asingle uninterruptible power supply goes on battery;

FIG. 5 is a high-level block diagram showing the system of FIG. 3 whenboth uninterruptible power supplies go on battery;

FIG. 6 is a high-level block diagram showing other components that maymonitor the supply of power to a storage system such as that illustratedin FIG. 2;

FIG. 7 is a high-level block diagram showing the system of FIG. 6 when asingle uninterruptible power supply goes on battery;

FIG. 8 is a high-level block diagram showing the system of FIG. 6 whenboth uninterruptible power supplies go on battery; and

FIG. 9 is a state diagram showing various states of a UPS code objectwithin a hardware management console.

DETAILED DESCRIPTION

It will be readily understood that the components of the presentinvention, as generally described and illustrated in the Figures herein,could be arranged and designed in a wide variety of differentconfigurations. Thus, the following more detailed description of theembodiments of the invention, as represented in the Figures, is notintended to limit the scope of the invention, as claimed, but is merelyrepresentative of certain examples of presently contemplated embodimentsin accordance with the invention. The presently described embodimentswill be best understood by reference to the drawings, wherein like partsare designated by like numerals throughout.

The present invention may be embodied as a system, method, and/orcomputer program product. The computer program product may include acomputer readable storage medium (or media) having computer readableprogram instructions thereon for causing a processor to carry outaspects of the present invention.

The computer readable storage medium may be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages.

The computer readable program instructions may execute entirely on auser's computer, partly on a user's computer, as a stand-alone softwarepackage, partly on a user's computer and partly on a remote computer, orentirely on a remote computer or server. In the latter scenario, aremote computer may be connected to a user's computer through any typeof network, including a local area network (LAN) or a wide area network(WAN), or the connection may be made to an external computer (forexample, through the Internet using an Internet Service Provider). Insome embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, may be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus, or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

Referring to FIG. 1, one example of a network environment 100 isillustrated. The network environment 100 is presented to show oneexample of an environment where embodiments of the invention mayoperate. The network environment 100 is presented only by way of exampleand not limitation. Indeed, the systems and methods disclosed herein maybe applicable to a wide variety of different network environments inaddition to the network environment 100 shown.

As shown, the network environment 100 includes one or more computers102, 106 interconnected by a network 104. The network 104 may include,for example, a local-area-network (LAN) 104, a wide-area-network (WAN)104, the Internet 104, an intranet 104, or the like. In certainembodiments, the computers 102, 106 may include both client computers102 and server computers 106 (also referred to herein as “hosts” 106 or“host systems” 106). In general, the client computers 102 initiatecommunication sessions, whereas the server computers 106 wait for andrespond to requests from the client computers 102. In certainembodiments, the computers 102 and/or servers 106 may connect to one ormore internal or external direct-attached storage systems 112 (e.g.,arrays of hard-disk drives, solid-state drives, tape drives, etc.).These computers 102, 106 and direct-attached storage systems 112 maycommunicate using protocols such as ATA, SATA, SCSI, SAS, Fibre Channel,or the like.

The network environment 100 may, in certain embodiments, include astorage network 108 behind the servers 106, such as astorage-area-network (SAN) 108 or a LAN 108 (e.g., when usingnetwork-attached storage). This network 108 may connect the servers 106to one or more storage systems 110, such as arrays 110 a of hard-diskdrives or solid-state drives, tape libraries 110 b, individual hard-diskdrives 110 c or solid-state drives 110 c, tape drives 110 d, CD-ROMlibraries, or the like. To access a storage system 110, a host system106 may communicate over physical connections from one or more ports onthe host 106 to one or more ports on the storage system 110. Aconnection may be through a switch, fabric, direct connection, or thelike. In certain embodiments, the servers 106 and storage systems 110may communicate using a networking standard such as Fibre Channel (FC)or iSCSI.

Referring to FIG. 2, one embodiment of a storage system 110 a containingan array of storage drives 204 (e.g., hard-disk drives and/orsolid-state drives) is illustrated. The internal components of thestorage system 110 a are shown since the systems and methods disclosedherein may, in certain embodiments, be implemented within such a storagesystem 110 a, although the systems and methods may also be applicable toother storage systems. As shown, the storage system 110 a includes astorage controller 200, one or more switches 202, and one or morestorage drives 204 such as hard disk drives and/or solid-state drives(such as flash-memory-based drives). The storage controller 200 mayenable one or more hosts 106 (e.g., open system and/or mainframe servers106) to access data in the one or more storage drives 204.

In selected embodiments, the storage controller 200 includes one or moreservers 206. The storage controller 200 may also include host adapters208 and device adapters 210 to connect the storage controller 200 tohost devices 106 and storage drives 204, respectively. During normaloperation (when both servers 206 are operational), the servers 206 maymanage I/O to different logical subsystems (LSSs) within the enterprisestorage system 110 a. For example, in certain configurations, a firstserver 206 a may handle I/O to even LSSs, while a second server 206 bmay handle I/O to odd LSSs. These servers 206 a, 206 b may provideredundancy to ensure that data is always available to connected hosts106. Thus, when one server 206 a fails, the other server 206 b may pickup the I/O load of the failed server 206 a to ensure that I/O is able tocontinue between the hosts 106 and the storage drives 204. This processmay be referred to as a “failover.”

In selected embodiments, each server 206 includes one or more processors212 and memory 214. The memory 214 may include volatile memory (e.g.,RAM) as well as non-volatile memory (e.g., ROM, EPROM, EEPROM, flashmemory, local disk drives, local solid state drives etc.). The volatileand non-volatile memory may, in certain embodiments, store softwaremodules that run on the processor(s) 212 and are used to access data inthe storage drives 204. These software modules may manage all read andwrite requests to logical volumes in the storage drives 204.

In selected embodiments, the memory 214 includes a cache 218, such as aDRAM cache 218. Whenever a host 106 (e.g., an open system or mainframeserver 106) performs a read operation, the server 206 that performs theread may fetch data from the storages drives 204 and save it in itscache 218 in the event it is required again. If the data is requestedagain by a host 106, the server 206 may fetch the data from the cache218 instead of fetching it from the storage drives 204, saving both timeand resources. Similarly, when a host 106 performs a write, the server106 that receives the write request may store the write in its cache218, and destage the write to the storage drives 204 at a later time.When a write is stored in cache 218, the write may also be stored innon-volatile storage (NVS) 220 of the opposite server 206 so that thewrite can be recovered by the opposite server 206 in the event the firstserver 206 fails. In certain embodiments, the NVS 220 is implemented asbattery-backed volatile memory in the opposite server 206.

One example of a storage system 110 a having an architecture similar tothat illustrated in FIG. 2 is the IBM DS8000™ enterprise storage system.The DS8000™ is a high-performance, high-capacity storage controllerproviding disk and solid-state storage that is designed to supportcontinuous operations. Nevertheless, the systems and methods disclosedherein are not limited to the IBM DS8000™ enterprise storage system 110a, but may be implemented in any comparable or analogous storage systemor group of storage systems, regardless of the manufacturer, productname, or components or component names associated with the system. Anystorage system that could benefit from one or more embodiments of theinvention is deemed to fall within the scope of the invention. Thus, theIBM DS8000™ is presented only by way of example and is not intended tobe limiting.

Referring to FIG. 3, when a storage system 110 a such as thatillustrated in FIG. 2 experiences a power outage, the modified data inthe NVS 220 may be quickly copied (also referred to as performing a“fire hose dump”) under battery power to more persistent storage (alocal disk drive, solid state drive, flash drive, etc. in the server206). Ideally, this copy process will complete before energy in thebattery is depleted. It follows that the energy in the battery needs tobe sufficient to complete the copy process. If a battery is degraded orthe copy process is not initiated quickly enough after the storagesystem goes on battery power, the battery may not have sufficient energyto complete the copy process. In such cases, data loss may result. Insuch cases, modified data in the NVS 220 may be all or partially lost.

FIG. 3 is a high-level block diagram showing various components that maybe associated with supplying power to a storage system 110 a such asthat illustrated in FIG. 2. As shown, the storage system 110 a includesa pair of servers 206 a, 206 b. Each server 206 may host one or morelogical partitions 300, each of which may have non-volatile storage(NVS) 220 associated therewith to store modified data. Each server 206may include a hypervisor 302 to provide isolation between the logicalpartitions 300. The hypervisors 302 may coordinate and manage systemvirtualization, including creating logical partitions 300 anddynamically moving resources across different operating environments.

As further shown in FIG. 3, the storage system 110 a may include rackpower controllers 308. These rack power controllers 308 may manage powerdistribution and efficiency within the storage system 110 a. As furthershown in FIG. 3, each rack power controller 308 may be coupled to anuninterruptible power supply 310 that provides power to the storagesystem 110 a. The uninterruptible power supplies 310 may include abackup battery to supply power to the storage system 110 a when externalpower is interrupted. This may enable data to be copied from thenon-volatile storage 220 to more persistent storage before energy in thebattery is depleted.

As shown in FIG. 3, the uninterruptible power supplies 310 may supplypower to the storage system 110 a. Each uninterruptible power supply 310may supply power (either external power or battery power) to bothservers 206 in the storage system 110 a. This provides redundancy toensure that, if an uninterruptible power supply 310 fails, the remaininguninterruptible power supply 310 will still be available to supply powerto the servers 206.

In certain embodiments in accordance with the invention, a dump ofmodified data (i.e., a “fire hose dump”) may only be initiated when bothuninterruptible power supplies 310 have experienced external power lossand are operating “on battery.” This fire hose dump may be initiated byeither rack power controller 308 when the rack power controller 308becomes aware that both uninterruptible power supplies 310 are onbattery. Systems and methods in accordance with the invention may ensurethat both rack power controllers 308 are aware when one or bothuninterruptible power supplies 310 are on battery, even withoff-the-shelf uninterruptible power supplies 310 that have a single “onbattery” communication line and can only connect to a single rack powercontroller 308.

In certain embodiments in accordance with the invention, rack powercontrollers 308 may be configured to communicate the battery status oftheir respective uninterruptible power supplies 310 with each other. Forexample, as shown in FIG. 4, if a first rack power controller 308 adetects that its uninterruptible power supply 310 has experienced apower outage and is on battery, the first rack power controller 308 amay communicate this status to a second rack power controller 308 b. Ifthe second rack power controller 308 b does not detect a correspondingpower outage and on-battery status for its uninterruptible power supply310 b, the second rack power controller 308 b may take no action. Thatis, the second rack power controller 308 may make no attempt to initiatea fire hose dump on the first and second servers 206 a, 206 b.

On the other hand, if the second rack power controller 308 b detectsthat its uninterruptible power supply 310 b has also experienced a poweroutage and is on battery, as shown in FIG. 5, the second rack powercontroller 308 b may be aware that both uninterruptible power supplies310 are on battery. In such a scenario, the second rack power controller308 b may communicate failure status to each server 206. This failurestatus may trigger a fire hose dump on both servers 206.

Similarly, for redundancy purposes, the second rack power controller 308b may, upon detecting that its uninterruptible power supply 310 b is onbattery, send on-battery status to the first rack power controller 308a. The first rack power controller 308 a, now being aware that bothuninterruptible power supplies 310 are on battery, may send failurestatus to both servers 206, thereby initiating a fire hose dump on bothservers 206 if the fire hose dump has not already been initiated. Thus,when both uninterruptible power supplies 310 experience a power outageand are on battery, both rack power controllers 308 may detect theon-battery status of both uninterruptible power supplies 310. Inresponse, each rack power controller 308 may independently initiate firehose dumps on both servers 206.

In certain embodiments, when a server 206 receives failure status from arack power controller 308, a flexible service processor (FSB) 304 withinthe server 206 may receive this failure status and pass the status tothe server's hypervisor 302. In response to receiving this failurestatus, the hypervisor 302 may initiate the fire hose dump within eachlogical partition 300 of the server 206. Alternatively, or additionally,failure status may be communicated through a serial adapter 306 on eachserver 206 to initiate the fire hose dump.

Referring to FIG. 6, other methods and techniques for initiating a firehose dump are possible and within the scope of the invention. Forexample, in certain embodiments, uninterruptible power supplies 310 mayinclude ports, such as ethernet ports, to connect the uninterruptiblepower supplies 310 to network devices such as ethernet switches 602.Similarly, hardware management consoles 600 may be used to manage,monitor, and service the servers 206 on the storage system 110 a. Thehardware management consoles 600, like the uninterruptible powersupplies 310, may include ports, such as ethernet ports, to connect thehardware management consoles 600 to the ethernet switches 602 to enablecommunication with the servers 206 and uninterruptible power supplies310.

In certain embodiments, the uninterruptible power supplies 310 may beconfigured to generate alert messages, such as Simple Network ManagementProtocol (SNMP) traps, when events occur on the uninterruptible powersupplies 310. For example, the uninterruptible power supplies 310 maygenerate SNMP traps when the uninterruptible power supplies 310experience a power outage and go on battery. In such cases, the SNMPtraps may be communicated to the respective hardware management consoles600. For example, a first hardware management console 600 a may receivean SNMP trap associated with a first uninterruptible power supply 310 a,and a second hardware management console 600 b may receive an SNMP trapassociated with a second uninterruptible power supply 310 b when therespective uninterruptible power supplies 310 a, 310 b experience apower outage and go on battery.

When a hardware management console 600 receives an SNMP trap from itsrespective uninterruptible power supply 310, the hardware managementconsole 600 may process the SNMP trap and update an internal UPS codeobject to indicate that the uninterruptible power supply 310 is in theon-battery state. Similarly, the hardware management console 600 maycommunicate the on-battery status of its uninterruptible power supply310 to the other hardware management console 600.

For example, as shown in FIG. 7, when a second uninterruptible powersupply 310 b experiences a power outage and goes on battery, the seconduninterruptible power supply 310 b may generate an SNMP trap. This SNMPtrap may be communicated to the second hardware management console 600 bthrough the ethernet switch 602 b. Upon receiving the SNMP trap, thesecond hardware management console 600 b may update its UPS code objectto indicate that its uninterruptible power supply 310 b is on battery.The hardware management console 600 b may then communicate thison-battery status to the other hardware management console 600 a throughthe ethernet switch 602 a. Upon receiving the on-battery status, thefirst hardware management console 600 a may update is internal UPS codeobject to indicate that the second uninterruptible power supply 310 b ison battery. If the first hardware management console 600 a does notdetect a corresponding power outage and on-battery status for itsuninterruptible power supply 310 a, the first hardware managementconsole 600 a may do nothing. That is, the first hardware managementconsole 600 a may not attempt to initiate a fire hose dump or otheremergency measure on the first and second servers 206 a, 206 b.

If, on the other hand, the first hardware management console 600 adetects that its uninterruptible power supply 310 a has also experienceda power outage and is on battery, as shown in FIG. 8, the first hardwaremanagement console 600 a may update its internal UPS code object toindicate that the first uninterruptible power supply 310 a is onbattery. In such a case the first hardware management console 600 a mayknow that both uninterruptible power supplies 310 a, 310 b are onbattery. In such a scenario, the first hardware management console 600 amay communicate failure status to both rack power controllers 308 a, 308b (via, for example, the flexible service processor 304 previouslydiscussed), indicating that the storage system 110 a is now running onbattery. The rack power controllers 308 may then know that bothuninterruptible power supplies 310 are on battery and initiate fire hosedumps on both servers 206 in the manner previously described inassociation with FIGS. 3 through 5. Alternatively, the hardwaremanagement console 600 a may directly initiate the fire hose dump on theservers 206 (via, for example, the flexible service processors 304)without requiring initiation by the rack power controllers 308.

Similarly, for redundancy purposes, the first hardware managementconsole 600 a may, upon detecting that its uninterruptible power supply310 a is on battery, send on-battery status to the second hardwaremanagement console 600 b. The second hardware management console 600 b,now knowing that both uninterruptible power supplies 310 a, 310 b are onbattery, may also send failure status to both rack power controller 308a, 308 b (or alternatively, directly to both servers 206), therebyinitiating fire hose dumps on both servers 206 if they have not alreadybeen initiated. Thus, when both uninterruptible power supplies 310experience a power outage and are on battery, both hardware managementconsoles 600 a, 600 b may detect on-battery status associated with bothuninterruptible power supplies 310 and independently initiate fire hosedumps either directly or indirectly on both servers 206.

FIG. 9 is a state diagram showing various states of a UPS code objectwithin a hardware management console 600. As shown, when anuninterruptible power supply 310 associated with a hardware managementconsole 600 is available and not on battery, the UPS code objectassociated with the uninterruptible power supply 310 in the hardwaremanagement console 600 is set to “UPS Available.” When the hardwaremanagement console 600 receives an SNMP trap indicating that theuninterruptible power supply 310 has experienced a power outage and ison battery, the UPS code object may be set to “On Battery.” The hardwaremanagement console 600 a may remain in this state as long as theuninterruptible power supply 310 of the partner hardware managementconsole 600 is available and not on battery. While the UPS code objectis in the “On Battery” state, if the hardware management console 600detects that the uninterruptible power supply 310 of its partnerhardware management console 600 is also on battery or unavailable, thehardware management console 600 may instruct the rack power controllers308 to initiate a fire hose dump.

The flowcharts and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowcharts or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the Figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. Other implementationsmay not require all of the disclosed steps to achieve the desiredfunctionality. It will also be noted that each block of the blockdiagrams and/or flowchart illustrations, and combinations of blocks inthe block diagrams and/or flowchart illustrations, may be implemented byspecial purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

1. A method for protecting data in a storage system, the methodcomprising: detecting, by a first hardware management console, firstbattery-on status associated with a first uninterruptible power supply;detecting, by a second hardware management console, second battery-onstatus associated with a second uninterruptible power supply;communicating, from the first hardware management console to the secondhardware management console, the first battery-on status; andtriggering, by the second hardware management console, a dump ofmodified data from memory upon detecting both the first battery-onstatus and the second battery-on status.
 2. The method of claim 1,wherein detecting the first battery-on status comprises receiving, bythe first hardware management console, a first alert message from thefirst uninterruptible power supply indicating the first battery-onstatus.
 3. The method of claim 2, wherein detecting the secondbattery-on status comprises receiving, by the second hardware managementconsole, a second alert message from the second uninterruptible powersupply indicating the second battery-on status.
 4. The method of claim3, wherein the first and second alert messages are Simple NetworkManagement Protocol (SNMP) traps.
 5. The method of claim 1, whereintriggering the dump comprises communicating the first battery-on statusand the second battery-on status to a rack power controller whichinitiates the dump.
 6. The method of claim 1, wherein triggering thedump comprises directly initiating the dump on multiple storage serversof an enterprise storage system.
 7. The method of claim 1, whereininitiating the dump comprises copying the modified data from the memoryto persistent storage.
 8. A computer program product for protecting datain a storage system, the computer program product comprising acomputer-readable storage medium having computer-usable program codeembodied therein, the computer-usable program code configured to performthe following when executed by at least one processor: detect, by afirst hardware management console, first battery-on status associatedwith a first uninterruptible power supply; detect, by a second hardwaremanagement console, second battery-on status associated with a seconduninterruptible power supply; communicate, from the first hardwaremanagement console to the second hardware management console, the firstbattery-on status; and trigger, by the second hardware managementconsole, a dump of modified data from memory upon detecting both thefirst battery-on status and the second battery-on status.
 9. Thecomputer program product of claim 8, wherein detecting the firstbattery-on status comprises receiving, by the first hardware managementconsole, a first alert message from the first uninterruptible powersupply indicating the first battery-on status.
 10. The computer programproduct of claim 9, wherein detecting the second battery-on statuscomprises receiving, by the second hardware management console, a secondalert message from the second uninterruptible power supply indicatingthe second battery-on status.
 11. The computer program product of claim10, wherein the first and second alert messages are Simple NetworkManagement Protocol (SNMP) traps.
 12. The computer program product ofclaim 8, wherein triggering the dump comprises communicating the firstbattery-on status and the second battery-on status to a rack powercontroller which initiates the dump.
 13. The computer program product ofclaim 8, wherein triggering the dump comprises directly initiating thedump on multiple storage servers of an enterprise storage system. 14.The computer program product of claim 13, wherein initiating the dumpcomprises copying the modified data from the memory to persistentstorage.
 15. A system for protecting data in a storage system, thesystem comprising: at least one processor; at least one memory deviceoperably coupled to the at least one processor and storing instructionsfor execution on the at least one processor, the instructions causingthe at least one processor to: detect, by a first hardware managementconsole, first battery-on status associated with a first uninterruptiblepower supply; detect, by a second hardware management console, secondbattery-on status associated with a second uninterruptible power supply;communicate, from the first hardware management console to the secondhardware management console, the first battery-on status; and trigger,by the second hardware management console, a dump of modified data frommemory upon detecting both the first battery-on status and the secondbattery-on status.
 16. The system of claim 15, wherein detecting thefirst battery-on status comprises receiving, by the first hardwaremanagement console, a first alert message from the first uninterruptiblepower supply indicating the first battery-on status.
 17. The system ofclaim 16, wherein detecting the second battery-on status comprisesreceiving, by the second hardware management console, a second alertmessage from the second uninterruptible power supply indicating thesecond battery-on status.
 18. The system of claim 17, wherein the firstand second alert messages are Simple Network Management Protocol (SNMP)traps.
 19. The system of claim 15, wherein triggering the dump comprisescommunicating the first battery-on status and the second battery-onstatus to a rack power controller which initiates the dump.
 20. Thesystem of claim 15, wherein triggering the dump comprises directlyinitiating the dump on multiple storage servers of an enterprise storagesystem.